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ABSTRACT 

This  thesis  Is  concerned  with  Che  recent  trend  towards 
decentralization  of  the  computer  facility.  We  conjecture  that  there  are 
strong  forces  In  many  organizations  leading  towards  decentralization,  which 
have  been  held  In  check  by  technological  and  economic  constraints  that  are 
beginning  to  relax.  This  conjecture  Is  explored  by  analyzing  ipproxlmately 
forty  case  studies  of  decentralization  decisions. 

The  results  Indicate  that  (1)  strong  decentralization  forces  do 
exist  In  many  organizations.  The  forces  derived  from  these  particular  case 
studies  are  classified  as  either  functional,  economic  or  psychological. 

(2)  The  drop  In  hardware  costs  allows  decentralization  to  occur  at  the 
Initiative  of  lower  level  managers. 

The  consequences  could  Include  disintegration  of  the 
organization's  Information  system.  Decisions  by  lower  level  managers  may 
overlook  the  technological  constraints  of  decentralization,  especially  the 
problems  of  networking  loosely  coupled  computers.  This  could  result  In  a 
future  Inability  to  share  data  or  programs  among  organizational  units. 
Because  of  the  many  functional  advantages  It  provides,  we  do  not  feel  that 
top  level  management  should  discourage  decentralization.  However,  top 
level  management  must  be  aware  that  the  technological  constraints  require 
that  decentralization  occur  with  their  guidance  and  their  perspective  of 
the  entire  organization. 
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INTRODUCTION 


1.1  Overview 

Currently,  there  Is  much  discussion  regarding  the  Issue  of 
centralization  versus  decentralization  of  an  organization's  computer-based 
Information  system.  While  a centralized  computing  facility  continues  to  be 
the  norm,  there  appears  to  be  a recent  trend  towards  decentralization. 

This  thesis  is  concerned  with  determining  and  examining  the  forces  behind 
these  decentralization  decisions. 

1.2  History  of  Computer  System  Organization 

The  question  of  how  to  match  the  computer-based  Information 
system  to  the  organization  has  plagued  management  for  years.  Traditionally 
the  first  computer  was  acquired  and  used  by  the  accounting  department, 
because  accounting  functions  were  well  suited  to  computer  processing.  As 
other  departments  became  Interested  In  applying  this  computer  to  their 
tasks,  problems  often  developed  In  establishing  priorities  for  the  use  of 
the  computer.  In  most  cases  these  organizational  conflicts  were  resolved 
by  establishing  a separate  data  processing  department  [1]. 

At  the  time  centralization  began.  It  was  considered  Infeasible  to 
allow  separate  departments  within  a firm  to  acquire  and  maintain  their  own 
computers.  First,  costs  for  hardware  were  prohibitive.  Second,  there  was 
a severe  shortage  of  technical  personnel.  Third,  management  saw  the 
computer  as  a means  of  centralizing  records  that  were  formerly  collected 
and  maintained  by  Individuals  or  groups.  A centralized  Information  system 
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would  allow  consolidation  of  reports  that  had  been  difficult  or  impossible 
previously  [2]. 

The  trend  during  the  late  1960's  was  towards  more  and  more 
centralization  of  the  Information  system  [3].  First,  economies  of  scale  in 
computer  hardware  became  a widely  accepted  idea  [4].  Second,  the 
combination  of  centralized  systems  and  the  new  technology  of  time-sharing 
seemed  to  make  a "Total  Management  Information  System"  for  the  organization 
a possibility.  At  that  time  one  might  have  predicted  that  by  1977  there 
would  be  very  little  debate  or  concern  about  how  to  organize  a 
computer-based  information  system. 

1.3  Why  the  Concern  Today? 

And  yet,  there  is  more  discussion  now  than  ever  before.  There 
appear  to  be  several  reasons  for  continuing  management  interest  in  this 
area.  First  in  spite  of  decreasing  hardware  costs,  EOF  (Electronic  Data 
Processing)  budgets  continue  to  climb  and  represent  an  increasingly  large 
part  of  an  organization's  expenditures.  Second,  organizations  as  a whole 
are  increasingly  dependent  on  their  Information  systems.  Third,  because 
information  systems  have  become  an  Important  part  of  management  many 
individual  managers  are  demanding  more  control  over  their  own  systems. 
Fourth,  technological  developments,  such  as  minicomputers,  offer  new 
alternatives  in  computer  system  organization,  because  of  their  low  entry 
costs  and  increasing  capabilities. 

It  is  assumed  that  a decentralized,  user-controlled,  environment 
will  Impact  issues  that  concern  management  differently  than  will  a 
centralized  environment.  For  this  reason  and  because  they  represent  the 
extremes  of  computer  configuration,  discussion  of  computer  system 
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: organization  has  focused  on  centralization  versus  decentralization.  A 

quick  scan  of  any  computer  community  journal  reveals  that  centralization- 
decentralization  is  one  of  the  most  heatedly  debated  issues  in  the 
' management  of  information  systems  today. 


1 


1 


1.4  What  is  Computer  Decentralization? 

The  concept  of  decentralization  is  not  a new  one  in  the  computer 
community.  The  earliest  computer  installations  in  business  firms  were 
excellent  examples  of  deceutralized  computing.  The  end  user,  in  most  cases 
the  accounting  department,  was  responsible  for  developins^  applications, 
maintaining  and  managing  the  system.  Both  the  computer  and  the  technical 
personnel  required  to  support  it  were  located  in  the  accounting  department  [1]. 

It  was  not  until  other  organizational  units  became  interested  in 
this  new  electronic  tool  that  the  trend  toward  centralization  began.  The 
result  was  that  the  machine,  support  personnel  and  responsibility  moved  out 
of  the  user  department  to  a new  and  separate  unit — the  data  processing 
department . 

It  is  obvious  that  computer  system  configuration  is  not  limited 
to  either  a totally  decentralized  or  totally  centralized  system.  For 
example,  an  organization  may  maintain  an  otherwise  totally  centralized  EDP 
department  but  "spin-off",  l.e.,  decentralize  one  particular  function.  In 
fact  some  authors  [5,6]  point  out  that  there  are  three  major  activities 
involved  in  the  information  system  function,  any  or  all  of  which  may  be 
centralized  or  decentralized  or  somewhere  between — making  the  variations 
between  totally  centralized  or  decentralized  almost  infinite.  These 
activities  arc; 
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1.  systems  operations — the  process  of  receiving  Input,  updating 
flies  and  generating  reports. 

2.  systems  development — the  process  of  designing  and  Implementing 
new  systems  and  applications. 

3.  systems  management — the  process  of  planning  and  establishing 
policy  for  the  data  processing  function. 

Another  term  referring  to  decentralized  computer-based 
Information  systems  Is  "distributed  processing."  While  It  has  been  defined 
In  many  ways.  Its  basic  meaning  Is  that  processing  power  Is  moved  out  of 
the  central  computer  room^to  local  sites.  The  only  distinguishing 
characteristic  between  distributed  processing  and  decentralization  Is  that 
distributed  processing  Implies  central  planning.  Decentrallzaton  may  or 
may  not  be  the  result  of  central  planning. 

This  thesis  will  use  loose  definitions  of  the  terms 
centralization  and  decentralization.  As  has  been  noted,  there  are  many 
variations  of  computer  organization.  It  Is  unlikely  that  any  two  firms 
will  organize  computer  resources  In  exactly  the  same  way.  For  this  reason 
It  makes  sense  to  deal  more  with  the  concepts  rather  than  with  precise 
definitions.  The  concept  of  centralization  is  that  processing  Is  carried 
out  by  a specialized,  central  group  for  an  end-user  community.  The  concept 
of  decentralization  is  that  the  processing  power  Is  acquired  and 
administered  by  the  end  user. 

1.5  Related  Research 

There  Is  an  abundance  of  literature  related  to  the  role  of  the 
computer  system  In  the  organization.  To  some  extenc,  all  of  this 
literature  relates  to  or  Is  background  to  this  thesis. 
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As  early  as  1957,  several  authors  conjectured  about  the  probable 
effects  of  computers  on  organizations.  These  authors  explored  questions 
about  how  the  ability  of  the  computer  to  store  and  consolidate  large 
amounts  of  Information  would  lnq>act  organizational  structure.  Some  authors 
felt  that  management  would  become  much  more  centralized  because  of  the 
ability  of  top  executives  to  access  large  amounts  of  Information  through 
the  computer.  Other  authors  saw  the  computer  as  a vehicle  to  further 
management  decentralization  [7]. 

Many  authors  have  explored  the  various  alternatives  available  In 
computer  system  organization,  and  the  use  of  computers  In  organizations. 

In  The  Real  Computer : Its  Inf luences . Uses  and  Effects.  Frederic  Ulthlngton 
presents  numerous  case  studies  citing  the  use  of  computers  In  organizations 
as  well  as  the  alternative  structures  that  these  systems  assume  [3]. 

Recently,  much  literature  has  been  addressed  to  the  debate 
between  centralization-decentralization  of  the  organizational  computer 
system.  In  an  effort  to  determine  the  "best"  structure.  This  discussion 
has  centered  on  the  advantages  and  disadvantages.  Rockart  has  developed  a 
bibliography  of  this  literature  [8] . 

Herbert  Crosch,  in  the  1940's,  was  the  first  to  present  views 
that  economies  of  scale  existed  In  the  use  of  computers.  This  became  known 
as  Grosch's  Law  and  has  been  the  major  argument  for  and  reason  behind 
centralization  of  the  computer  facility.  Various  authors  have  tested 
Grosch's  law  during  the  past  twenty  years  [9,10,11,12,13].  Selwyn  explored 
whether  users  feel  that  economies  of  scale  exist. [14] 

The  Center  for  Information  Systems  Research  at  the  M. I.T.  Sloan 
School  of  Management  has  developed  a model  for  declslon-maklng  regarding 
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computer  system  organization.  This  model  Is  presented  In  a 1976  working 


paper  from  CISR  [8].  The  model  Is  partly  based  on  Information  obtained 


through  case  studies  from  the  literature.  The  findings  from  the  case 


studies  are  summarized  In  the  CISR  paper 


A more  enlightening  approach  to  this  Issue  may  be  to  determine 


the  forces  that  are  actually  significant  In  decisions  regarding 


decentralization.  The  goal  of  this  approach  Is  not  to  define  the  "best 


decentralization  decisions  are  made  by  managers  at  either  a corporate  or 


operational  level.  This  Is  done  by  examining  case  studies  and  analyzing 


the  forces  at  work  In  the  organizations  studied 


organizations  leading  towards  decentralization  that  have  been  held  In  check 


until  now  by  technological  and  economic  constraints.  If  this  conjecture  Is 


true,  It  Is  significant  for  two  reasons.  First,  It  will  be  difficult  In 


the  future  for  an  organization  to  suppress  strong  forces  from  within,  even 


If  the  philosophy  of  the  organization  favors  centralization  of  the 


computing  facility.  The  economic  constraint  Is  vanishing  as  hardware  costs 


drop.  The  technological  constraint  refers  to  the  difficulty  of  sharing 


Information  among  loosely  coupled  computers.  This  Is  a significant 


constraint  at  present  but  It  Is  not  unrealistic  to  assume  that  the 


technological  problems  will  be  solved  In  the  future.  Second,  these  forces 


may  result  In  decisions  that  Ignore,  overlook  or  underestimate  the  present 


technological  constraint.  For  example.  It  Is  now  possible  for  computer 


acquisitions  to  occur  at  low  organizational  levels  because  of  the  drop  In 
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hardware  coata.  The  reault  of  theae  localized  declaions  could  be 
difficultiea  in  the  future  for  organizational  unite  dealring  to  ahare  data 
or  prograaa.  Therefore  aoae  thought  ahould  be  given  now  to  overall  aystea 
integration. 


PRELIMINARY  DISCUSSION  OF  FORCES 


Decentralization  decisions  may  be  initiated  at  different 
managerial  levels.  It  is  apparent  that  some  decentralization  occurs  at  the 
initiative  of  operations  (department)  level  managers  who  opt  for  acquiring 
a small  computer,  which  they  dedicate  to  their  application,  rather  than 
sharing  in  the  use  of  a large  central  system.  Decentralization  decisions 
are  also  made  by  corporate  level  management.  It  is  likely  that  there  are 
different  forces  behind  decisions  made  at  different  managerial  levels 
because  different  perspective*  are  involved.  The  operational  manager  is 
more  concerned  with  the  day-to-day  aspects  of  runnJ.ng  a department.  The 
corporate  level  manager  is  concerned  with  the  long-range  aspects  of  running 
the  entire  organization.  This  thesis  examines  the  forces  behind  decisions 
made  at  both  levels. 

Preliminary  study  of  the  literature  suggested  specific  forces 

that  might  be  significant  in  decentralization  decisions.  These  evident 

forces  seen  to  fall  into  three  categories:  functional,  economic  and 

psychological.  These  categories  are  broad  and  it  is  not  always  clear  in 

which  category  a particular  force  should  fall.  However,  the  categorization 

provides  a conceptual  framework  trhich  was  helpful  in  analyzing  the  forces 

behind  decentralization  decisions. 

A psychological  force  is  one  whose  source  is  an  emotion,  a 
philosophy,  a preference  or  a perception. 

A functional  force  is  based  on  the  ability  of  a particular 
configuration  to  accomplish  its  task.  This  collection  of  forces 
seems  to  parallel  many  formerly  noted  advantages  and 
disadvantages. 

Economic  forces  are  those  based  on  costs. 
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Section  2 Prellmiaary  Discussion  of  Forces 

This  thesis  does  not  present  forces  as  advantages  or 
disadvantages  of  decentralization  since  we  do  not  attempt  to  define  the 
"best"  structure  of  an  Information  system.  It  may  be  true  that  many 
"advantages"  of  decentralization  are  In  fact  "forces"  behind  user  decisions 
to  decentralize.  However,  advantages  and  disadvantages  reflect  an 
"objective"  view  of  the  decision  In  terms  of  Its  ultimate  effect  on  the 
organization.  One  might  assume  that  managerial  decisions  are  more  complex 
than  this. 
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3. 1 Method 

The  purpose  of  this  thesis  is  to  deteralne  forces  significant  to 
user  decisions  regarding  decentralisation.  The  most  reasonable  way  of 
determining  these  forces  is  through  examination  of  actual  case  studies. 

Over  forty  case  studies  were  collected  as  part  of  this  research. 
The  most  available  source  was  the  literature.  Many  cases  \tere  obtained 
from  articles  in  Compute rwor Id.  Datamation  or  other  computer  community 
Journals.  In  some  instances  additional  information  was  obtained  from  the 
organization  after  initially  reading  about  the  case  in  a journal. 
j Additional  sources  Include  other  authors'  experiences  and  case  studies 

related  by  the  marketing  department  of  a computer  manufacturer.  (Because 
they  were  obtained  under  an  agreement  of  confidentiality,  the  latter  case 
studies  are  disguised  here.)  Appendix  A contains  a listing  of  the  case 
studies  used  in  this  thesis.  This  listing  consists  of  the  name  of  the 
firm,  or  a description  of  the  firm's  activities,  the  source  of  the  case 
study,  and  the  sections  in  this  thesis  that  refer  to  that  case  study.  Each 
case  study  has  a unique  alphabetic  code  which  is  used  whenever  that  case 
study  is  referred  to.  This  code  may  be  used  to  cross  reference  through 
Appendix  A. 

Because  of  the  stated  purpose  of  this  thesis  most  of  the  case 
studies  examined  concerned  decentralization  decisions.  However  a few  case 
studies  were  examined  and  are  presented  because  they  represent  typical 
centralization  decisions. 
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This  problea  constrains  the  thesis  in  a number  of  ways.  The  most 
crucial  constraint  Is  that  It  is  possible  that  the  forces  that  are  revealed 
through  this  type  of  research  are  not  those  really  significant  to 
decisions.  It  is  possible  that  many  significant  forces  will  not  appear  In 


print,  especially  the  conjectured  psychological  forces.  Therefore,  It  Is 
necessary  to  "read  between  the  lines"  in  some  cases.  However,  %fhen  this  is 
done  It  is  acknowledged. 

3.2  Functional  Forces 

Functional  forces  refer  to  those  forces  that  are  based  upon  the 
ability  of  a computer  system  to  accomplish  some  desired  function. 

Many  of  the  forces  behind  the  decentralization  decisions  examined 
were  functional  forces.  Although  these  forces  were  significant  In  the 
declslon-oiaklng  process,  nothing  Is  Implied  about  the  eventual  performance 
of  the  system  In  the  case  study. 

Table  1 lists  the  functional  forces  that  were  found  to  exist  In 
the  case  studies  examined. 
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TABLE  I. 

FUNCTIONAL  FORCES  FOUND 
Flexibility 

Availability  and  Accessibility 
Ability  to  Set  Priorities 
Ability  to  Regulate  Response  Time 
Ability  to  Regulate  Hardware  and  Software  Upgrades 
Avoidance  of  Overhead  on  Mainframe 
Shorter  Development  Because  Less  Complexity 
Privacy  and  Security  Issues 
Reliability 


3.2.1  Flexibility 

The  word  that  best  sums  up  functional  forces  is  flexibility.  The 
vice-president  of  manufacturing  of  a small  firm  (case  A)  that  switched  its 
inventory  and  production  control  system  to  a mini  from  a service  bureau 
said,  "Outside  services  are  not  tuned  to  the  needs  of  a small  operation. 

If  you  want  real  flexibility  you  have  to  control  the  computer  yourself." 

Local  control  of  operations  gives  the  user  the  flexibility  to 
regulate  response  time  and  time  of  availability,  set  priorities  and 
schedule  system  upgrade.  It  also  allows  easy  accessibility  to  the  system. 
Each  of  these  was  a ujor  force  in  decentralization  decisions. 
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3.2.2  Availebiilty  and  Accessibility 

An  Insurance  firm's  actuarial  department  (case  B)  obtained  a 

dedicated  minicomputer  system.  According  to  the  anonymouo  user  they  wanted 

additional  availability  in  order  to  do  more  research. 

Before,  we  rejected  Jobs  because  they  would  have  taken  too  much 
time  on  the  time-sharing  system.  Nowadays  we  don't  mind  letting 
the  mini  run  four  or  five  hours. 

An  engineering  firm  (case  C)  was  considering  switching  from  a 
service  bureau  to  an  in-house  computer.  The  decision  was  between  acquiring 
a central  mainframe  computer  or  investing  in  separate  minicomputers  for 
each  regional  office.  The  decision  was  to  decentralize.  One  of  the 
reasons  given  was  that  local  engineers  could  then  be  encouraged  to  use  the 
computer  freely.  The  corporate  officers  felt  that  this  would  be  especially 
useful  if  a specific  Job  or  proposal  required  a large  amount  of  engineering 
calculations. 

Another  cue  involved  Lowe's  Companies  Inc.  (case  D),  a group  of 
140  building  materials  stores  spread  throughout  the  Southeast  United 
states.  Its  decentralization  decision  is  a total  one,  involving  both  store 
level  and  corporate  level  decentralization.  One  of  the  principles  behind 
the  design  of  the  corporate  system  is  that  it  is  dedicated  to  the  user. 

The  company  management  wanted  the  system  available  to  users  on  a full  time 
basis  to  provide  them  with  the  capability  to  do  what  they  want,  when  they 
want. 


Ricardo  Consulting  Engineers  of  Shoreham,  England  (case  E)  is  a 
former  user  of  a time-sharing  service.  One  reason  that  the  firm  purchased 
an  in-house  system  was  that  "availability  of  machine  time,  particularly  for 
large  Jobs  was  restricted"  on  the  service  bureau  uchine. 


■ 
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3.2.3  Ability  to  Set  Priorities 

The  ability  to  establish  priorities  Is  Important  to  an 
operational  manager.  Local  control  of  a computer  system  allows  the  manager 
of  the  unit  to  determine  what  Is  crucial  and  what  deserves  priority  in 
terms  of  computer  time  or  development  time.  A central  department  must  set 
priorities  among  a variety  of  users  and  if  a crucial  situation  arises  In 
more  than  one  unit,  one  user  must  be  given  preference.  If  an  operational 
manager  thinks  that  he  does  not  receive  enough  priority  then  he  may  seek 
local  processing  power.  This  force  Is  apparent  in  the  following  examples. 

The  controller's  division  of  Atlanta's  First  National  Bank  (case 
F)  acquired  Its  own  minicomputer  system  In  order  to  automate  much  of  Its 
clerical  work.  According  to  the  manager  of  accounting  services,  what  the 
division  felt  was  high  priority  did  not  seem  crucial  to  the  central  data 
processing  department.  If  the  division  wanted  this  new  capability  It  had 
to  develop  It.  This  disagreement  was  the  major  force  towards 
decent  ral Izat Ion . 

A representative  of  Deere  and  Company  (case  G)  related  his  firm's 
experiences  with  small  computer  users  within  the  organization  at  the  recent 
Spring  1977  National  Computer  Conference  In  Dallas.  The  firm  uses  six 
mainframes  as  a corporate  computing  utility.  Since  1975  the  central 
computer  department  has  conducted  an  annual  survey  of  users  to  determine 
where  small  computer  systems  were  being  used  within  the  company  as 
computers  rather  than  remote  job  entry  terminals.  In  1975  the  survey 
uncovered  35  small  computers.  In  1976  the  second  survey  revealed  102  small 
computers  and  In  this  year's  survey  150  small  computers  were  reported. 
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Although  the  company  representative  did  not  mention  the  forces  behind  these 
computer  acquisitions  he  did  say,  "An  added  Item  of  Interest  was  that  some 
of  the  applications  examined  took  only  days  to  liq>lement,  after  sitting  In 
the  request  queue  In  the  Business  Systems  Department  for  months." 

Closely  related  to  the  ability  to  set  priorities  Is  the  ability 
to  regulate  the  response  time  of  the  system. 

3.2.4  Ability  to  Regulate  Response  Time 

The  turnaround  time,  l.e.  the  response  time,  of  a computer  system 
Is  a major  determinant  of  effectiveness  of  the  system  In  many  applications. 
Response  time  may  refer  to  actual  machine  time,  which  Is  Important  In 
on-line  applications.  It  may  also  refer  to  total  turnaround  time  %rhlch 
Includes  computer  time,  transportation  of  data  to  the  centers  and  reports 
from  the  center.  The  ability  to  regulate  response  time  Is  related  to  the 
ability  to  set  priorities  In  that  decentralized  computing  allows  the 
manager  to  determine  %diat  response  time  his  department's  various 
applications  require  and  this  really  Involves  setting  priorities.  A 
slightly  different  perspective  regarding  response  time  Is  that  dedication 
of  a minicomputer  to  Interactive  use  gives  better  response  than  a general 
purpose  machine.  Glaser  states 

the  need  of  operating  managers  for  rapid  turnaround  of  operating 
Information  may  transcend  any  economies  that  might  be  provided 
by  sharing  data  processing  facilities  located  at  some  distance 
and  time  from  the  local  area  [6]. 

Dedication  of  a machine  to  an  application  allows  better  response  time  and 
decentralization  allows  the  manager  to  regulate  the  response  time.  Both  of 
these  seem  to  be  major  forces  towards  decentralization. 
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An  Insurance  firm's  actuarial  department  (case  B)  obtained  a 
dedicated  minicomputer  system  to  perform  actuarial  simulations.  The 
department  considered  using  the  firm's  data  processing  center  mainframe  but 
a benchmark  job  took  45  minutes  of  machine  time  as  opposed  to  17  minutes  on 
the  dedicated  minicomputer.  We  assume  that  this  is  because  the  central 
computer  is  processing  many  applications  at  one  time  (l.e. 
multiprogramming)  while  the  minicomputer  is  dedicated  (i.e.  processing  a 
small  number).  The  better  response  time  of  the  dedicated  implementation 
was  one  reason  that  the  department  chose  to  decentralize. 

The  corporate  division  of  a service  company  (case  H)  was  faced 
with  the  decision  of  whether  to  Implement  an  on-line  system  using  a mini  or 
by  placing  Che  system  on  a portion  of  a large  batch-processing  machine. 

The  company  realized  that  Che  peak  loading  periods  for  both  the  on-line 
system  (however  it  was  implemented)  and  Che  mainframe  would  occur  at  about 
the  same  time.  For  this  reason  a separate  machine  that  was  under  Che 
user's  direct  control  seemed  to  have  great  value  for  this  new  application. 
This  was  a major  reason  for  implementing  the  system  on  a dedicated  machine. 

In  a case  study  mentioned  previously  (case  E)  Ricardo  Consulting 
Engineers  of  Shoreham,  England,  switched  its  data  processing  from  a 
time-sharing  service  to  an  in-house  computer.  The  firm  found  Chat  it  was 
"approaching  the  limit  of  the  capabilities  of  time-sharing  systems.  In 
particular,  turnaround  time  was  considered  excessive,.  . ."  Rather  than 
reprogram  for  a more  powerful  time-sharing  service  they  acquired  an 
in-house  computer. 

Office  Canteens  of  Manhattan  (case  1)  recently  acquired  a small 
in-house  computer.  According  to  Che  controller,  "Before  we  installed  our 
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small  business  computer,  we  were  sending  all  our  data  out  to  be  processed 


by  an  IBM  System  3 o%med  by  another  division  of  our  corporation.  But  we 


weren't  getting  the  Information  needed  for  management  decisions 


response  to  the  profit  and  loss  picture  at  each  cafeteria  unit  was 


force  behind  the  decision  to  acquire  an  In-house  system. 

Chrysler  Corporation  (case  J)  decided  to  Implement  an  Interactive 


graphics  system  for  computer-aided  design.  Adding  this  capability  to  the 


central  machine  muld  have  compromised  the  response  time  of  both  the  old 


and  new  systems.  To  protect  the  response  time  of  both  the  new  and  old 


applications  Chrysler  Implemented  this  system  on  a mini 


Other  case  studies  mentioned  the  slow  response  time  of  a batch 


oriented  central  system  as  being  a decentralization  force.  A subtle  Issue 


In  these  cases  Is  that  the  organizations  have  made  a decision  not  to 


attempt  upgrade  of  the  central  system  so  that  It  Is  capable  of  on-line  real 


alternatives  the  organization  considered  before  deciding  to  decentralize 


Vfhlle  response  time  needs  are  the  most  apparent  decentralization  force  In 


these  particular  cases,  the  desire  to  avoid  system  upgrade  may  be  an 


unstated  but  major  underlying  force  In  these  decisions 


3.2.5  Regulating  Hardware  and  Software  Upgrades 


Service  upgrades  of  both  hardware  and  software  occur  with  some 


regularity  In  centralized  processing  departments.  The  reasons  for  the 


upgrades  may  be:  expansion  to  more  powerful  hardware,  replacement  of  a 


falling  unit.  Installation  of  a new  application  or  replacement  of  the 


operating  system  with  the  latest  edition.  These  service  disruptions  may 
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have  no  obvious  benefits  to  some  users  but  all  are  forced  to  suffer  the 
Inconvenience.  A local  system  will  experience  less  service  disruption  for 
upgrades  because  the  system  Is  less  complex  and  serves  fewer  users.  Less 
complexity  Implies  that  upgrades  will  be  less  difficult  and  therefore  less 
time-consuming.  Fewer  users  means  Chat  there  are  fewer  applications  which 
will  require  upgrade.  Service  disruptions  that  do  occur  will  have  obvious 
benefits  to  Chose  users.  In  the  extreme  case  of  one  user  Co  a system,  this 
user  will  Install  an  upgrade  only  If  he  perceives  a benefit.  The  following 
cases  are  examples  of  the  force  of  regulating  upgrades. 

A large  comserclal  bank  (case  K)  decentralized  operations  In  Its 
money  desk  department  (which  keeps  track  of  reserves,  and  transfers  money 
to  accounts  %fhen  needed)  by  dedicating  several  minis  to  separate 
applications.  This  approach  was  taken  because  It  %rould  allow  the 
department  to  automate  one  step  at  a time.  Expansion  or  upgrading  of 
functions  would  result  In  minimum  Interference  with  total  operations. 

Software  upgrades  tend  to  experience  further  problems  Chan 
service  disruption  during  Installation.  New  software  may  result  In  the 
sudden  appearance  of  "bugs",  which  must  be  tracked  down  and  corrected. 

These  "bugs"  will  tend  to  affect  service  for  a longer  duration  than  a 
temporary  disruption  for  upgrade.  A report  dealing  with  software 
reliability  [15]  states,  "Following  a new  release  software  failures  can 
lead  to  a considerable  reduction  In  serviceability."  The  report  documents 
the  average  extent  of  the  reduction  In  service  found  to  occur  In  several 
computer  installations  that  were  studied. 
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The  wide  variety  of  uses  of  malnfraae  systems  means  that  many 

"bugs”  show  up  In  some  applications  and  not  others.  The  same  report  says 

The  diversity  of  software  problems.  . .Indicates  that  different 
users  experience  different  problems  and  software  errors  have  high 
applications  dependency. 

These  application-dependent  bugs  may  necessitate  changes  In  software 
systems.  The  new  software  may  Impact  another  user  who  was  not  aware  of  or 
affected  by  the  Initial  problem.  This  Is  the  "Interfereace"  problem.  A 
decentralized  system  minimizes  the  Impact  of  one  user  on  another  because 
there  are  fewer  users  and  therefore  fewer  upgrades  of  software  are 
required.  Decentralized  systems  therefore  tend  to  avoid  this  problem. 

A case  Involving  a wholesale  manufacturing  company  (case  L) 
points  out  an  Interference  problem.  The  company  has  a central  facility 
that  serves  on-line  order  entry,  production  scheduling,  corporate 
accounting.  Inventory,  customer  billing,  etc.  - all  of  which  share  a large 
data  base.  The  central  computer  was  formerly  exclusively  batch  operation. 
However  two  years  ago  the  computer  was  upgraded  to  provide  on-line  order 
entry.  The  company  system  has  had  numerous  problems  with  the  mix  of  batch 
and  on-line  applications.  Formerly,  the  batch  process  ran  smoothly  but  now 
It  Is  beset  by  software  problems.  The  result  Is  that  applications  are 
delayed  or  not  run,  which  makes  users  unhappy  and  managers  frustrated. 


Results 


3.2.6  Desire  to  Avoid  Overhead  on  Mainframe 
I It  appeared  that  the  major  force  to  decentralize  In  some  case 

j i studies  was  the  need  to  Install  a new  application  and  the  desire  to  avoid 

any  upgrade  of  the  mainframe.  Although  the  reasons  that  these 
organizations  wanted  to  avoid  upgrade  were  not  stated  explicitly  we 
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conjecture  that  they  Involved  the  desire  to  avoid  overloading  the 
mainframe. 

For  example,  the  Retail  Installment  Loan  Department  of  Wachovia 
Bank  and  Trust  Company  of  Winston-Salem,  N.C.  (case  M)  acquired  a dedicated 
minicomputer  to  preprocess  Installment  loans  for  each  of  the  bank's  offices 
In  North  Carolina.  In  1971  the  department  was  using  the  bank's  central 
computer  to  process  these  loans.  They  had  at  various  times  used 
keypunching,  OCR  and  key-to-dlsk  for  data  entry  but  had  experienced 
problems  %rlth  each  of  these  methods.  Efficient  data  entry  required  an 
Interactive  system,  which  conceivably  could  have  been  Implemented  by 
upgrading  the  central  system.  Although  the  article  did  not  address  this 
point  It  appears  that  they  decided  against  this  kind  of  upgrade. 

Ollnkraft,  Inc.  Mill  Division  (case  N)  Installed  a dedicated  mini 
to  support  an  on-line  system.  This  decision  was  made  to  eliminate  the 
overhead  on  the  mainframe  that  would  be  associated  with  upgrading  It  to 
handle  on-line  systems.  The  mini  accumulates  transactions  during  the  day 
and  communicates  these  transactions  by  batch  mode  once  a day  to  the  central 
computer  which  processes  and  stores  large  amounts  of  data  relating  to  all 
the  Ollnkraft  Industries. 

A railroad  company  (case  0)  wished  to  automate  waybill 
preparation.  (The  waybill  Is  documentation  accompanying  every  freight 
shipment  and  contains  Information  on  source,  destination,  customer,  rate, 
etc.)  Corporate  management  considered  a centralised  system  using  remote 
on-line  terminals  but  discarded  this  Idea  because  of  the  high  overhead  that 
It  would  require  of  the  central  computer,  simply  to  handle  the 
communications.  They  chose  Instead  to  Install  mini  computers  at  each  of 
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seven  agencies.  These  agency  systesM  will  send  updates  to  a master  file  on 
the  central  computer  at  corporate  headquarters  but  will  maintain 
appropriate  subset  files  locally. 

Industrial  Nucleonics,  Inc.,  (case  P)  Implemented  a production 
and  Inventory  control  system  on  a dedicated  computer.  The  firm  Initially 
attempted  this  system  on  a central  computer.  However  It  experienced  data 
preparation  Inaccuracies  with  the  central  approach  because  the  keypuncher 
was  not  familiar  with  manufacturing  terms.  This  problem  might  have  been 
solved  by  decentralizing  personnel  responsible  for  data  entry  and 
Introducing 'an  on-line  data  entry  system,  but  It  appears  that  this  approach 
was  not  considered.  Perhaps  because  the  company  wished  to  avoid  any 
upgrade  of  the  mainframe.  It  decided  to  decentralize  the  entire  operation. 

3.2.7  Shorter  and  Easier  Development  of  Less  Complex  Systems 

Development  of  a system  to  run  on  a local  dedicated  computer  may 
be  faster  and  easier  to  accomplish  than  expanding  the  central  system  to 
Incorporate  the  new  application.  This  savings  In  time  and  ease  of 
development  may  encourage  decentralization. 

A comswrclal  bank  (case  K)  decentralized  operations  in  Its  money 
desk  department,  by  dedicating  each  of  several  minis  to  a different 
application.  This  approach  was  taken  after  initially  attempting  to 
automate  operations  through  a centralized  system.  With  a central  system, 
program  development  was  complex  and  therefore  a lengthy  process,  and  by  the 
time  an  application  was  developed  It  was  obsolete.  , After  years  of  problems 
they  decided  that  through  decentralization  each  application  could  be 
developed  in  six  to  nine  months  compared  to  the  typical  two  to  three  years 
for  a central  system. 
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A large  chemical  division  (case  Q)  consisting  of  several  remote 
profit  centers  In  addition  to  a corporate  headquarters  gave  most 
responsibility  for  handling  Information  needs  to  these  remote  locations. 

At  some  point,  central  management  recognized  a widespread  need  for  an 
on— line  transaction  oriented  system.  The  company  considered  tying  the 
profit  centers  directly  Into  the  computer  at  corporate  headquarters. 
However,  they  felt  that  aadlng  an  on-line  capability  to  the  central  system 
could  take  two  years  to  Implement.  The  decentralized  approach  was  used 
because  they  expected  that  the  development  time  of  this  Implementation 
would  be  six  months.  This  was  one  reason  that  the  company  chose  the 
decentralized  approach. 


3. 2. 8 Privacy  and  Security  Issues 

Privacy  of  Information  stored  In  computer  data  bases  has  been  a 
major  cause  of  concern  In  the  past  five  years,  most  noticeably  In 
government  computer  systems. 

As  early  as  1972  the  FBI  (case  R)  established  a security 
regulation  requiring  that  any  computer  that  handles  criminal  histories  be 
dedicated  to  law-enforcement  use  and  under  the  control  and  management  of 
law  enforcement  officials [cw20] . This  regulation  was  reaffirmed  In  a 1975 
ruling  by  the  Justice  Department,  which  called  for  states  receiving  federal 
funding  to  operate  criminal  Justice  Information  systems  on  dedicated 
computers. 

In  Hiroshima,  Japan,  In  1975  the  Central  Congress  for  Privacy 
Protection  (case  S)  protested  the  city's  plan  to  place  the  health  records 
of  victims  of  the  1945  atom  bombs  Into  a central  data  bank.  Other  Japanese 
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dsts  banks  had  been  established  without  privacy  objections.  It  seems, 
however,  that  the  Idea  of  centralizing  a data  base  brings  privacy 
considerations  to  the  foreground.  People  seem  to  be  more  comfortable  with 
the  Idea  of  decentralized  data  bases. 

In  1975  Arizona's  governor  (case  T)  opposed  consolidation  of  the 
Arizona  state  government  computer  systems  Into  a central  system  because  he 
felt  It  threatened  the  privacy  rights  of  Arizona  citizens. 

The  Georgia  State  Crime  Lab  (case  U)  uses  a minicomputer  to  keep 
track  of  evidence  used  In  criminal  trials.  The  lab  chose  a mini  over  other 
methods  because  It  needed  "the  security  of  an  Individual  system." 

Lockwood-McDonald  Hospital  (case  V)  formerly  used  a terminal 
connected  to  a service  bureau  computer  to  serve  Its  data  processing  needs. 
The  hospital  administrator,  explained  why  the  hospital  decided  to  obtain 
Its  own  small  computer.  "The  major  advantage  In  having  a small  compact, 
easy-to-use  computer  right  here  In  our  o%m  business  office  Is  the  ability 
to  enter  and  retrieve  Information  In  a timely,  completely  accurate,  totally 
secure  environment." 

3.2.9  Reliability 

There  are  circumstances  In  which  a sickle  centralized  computer 
facility  Is  not  sufficiently  reliable  to  provide  required  levels  of 
availability.  In  these  circumstances  a distributed  system  comprised  of 
several  nodes  Individually  capable  of  stand-alone  operations  may  provide  a 
configuration  that  continues  to  operate  as  a whole  If  one  or  more  of  the 
Individual  nodes  falls  [16]. 

In  a distributed  or  decentralized  system,  service  continues  to 
most  of  the  system  If  one  particular  node  falls.  The  failure  of  the 
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mainframe  computer  In  a centralized  system  results  In  total  loss  of  service 
throughout  the  system.  A central  system's  reliability  may  be  Increased  by 
using  a redundant  processor,  %fhlch  serves  as  a back--up  to  the  front 
processor.  However,  this  redundancy  may  not  decrease  vulnerability  to 
disaster  (such  as  fire,  flood,  etc.)  or  sabotage  because  the  two  processors 
are  usually  located  in  the  same  area. 

Several  case  studies  seemed  to  show  that  the  reliability  of  a 
decentralized  or  distributed  system  is  a force  in  decentralization 
decisions. 


Inter-Provincial  Pipeline  Company  (case  X)  is  a Canadian-U.S. 
company  that  uses  a distributed  network  of  mini  computers  to  monitor  and 
control  pipeline  and  pumping  stations.  Reliability  was  cited  as  the  major 
reason  for  choosing  this  structure. 

The  ARPANET  is  a computer  network  that  ties  together  the  computer 
systems  of  major  universities  and  research  laboratories  from  across  the 
United  States.  The  Inter-Message  Processor  (IMP)  system  (case  T)  is  a 
network  of  small  computers  dedicated  to  the  task  of  handling  communications 
between  host  computers  (i.e.  the  university  or  laboratory  computer)  in  the 
network.  The  IMP  computer  acknowledges  to  the  source  computer  that  its 
message  has  left  the  communicatlor;-'^  subnetwork  and  has  reached  the 
destination  host  computer.  The  IMP  is  not  subject  to  service  interruptions 
which  a host  computer  is  subject  to  because  it  serves  only  one  function. 
These  interruptions  may  appear  as  a crash  to  the  source  computer  because 
its  message  isn't  immediately  acknowledged,  when  in  fact  the  message  has 
been  received  and  will  be  processed  at  a later  date.  Because  the  IMP  is 
not  interruptable,  i.e.  it  is  dedicated  to  one  function,  "its  negative 
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acknowledgeaent  is  s aore  reliable  indication  of  message  non-delivery  than 


is  a timed  out  host  level  acknovledgeaent . In  addition  the  special  purpose 
IKP  machine  can  be  made  more  reliable  than  a general  purpose  host  which 
must  manage  failure  prone  mechanical  devices." 


Southern  Bell  Telephone  and  Telegraph  Co.  (case  Z) , with 


headquarters  in  Atlanta,  uses  seven  clusters  of  minicomputers  in  its 


service  order  application.  One  of  the  major  considerations  in  this 


decision  was  the  requirement  for  high  reliability 


In  the  1940's  Herbert  Grosch  argued  that  the  power  of  a computer 
system  increases  with  the  square  of  the  cost  of  the  system  [9].  In  other 
words,  if  you  pay  twice  as  much  for  a processor  you  receive  four  times  the 


processing  power.  This  argument  became  known  as  Grosch' s Law  and  has  been 


Che  center  of  much  debate  and  study.  Among  those  who  empirically  tested 


Grosch's  Law  were  Knight  [10,11],  Solomon  [12]  and  Littrel  [13].  Knight 


and  Solomon  concluded  that  economies  of  scale  did  exist.  Littrel's  study 


indicated  chat  the  law  held  for  scientific  calculations  but  not  for 


rcial  data  processing 


The  original  Grosch's  Law  referred  only  to  economies  of  scale  in 


the  hardware  that  provides  the  processing  power.  Supporters  of  the 
argument  have  extended  it  by  pointing  to  the  existence  of  economies 


associated  with  the  operations  of  large  systems  and  shared  development 


costs.  Hulciprogramaming,  usually  found  only  in  large  systems  has  also 
been  mentioned  because  it  seems  to  provide  another  economy  by  ridding  the 
system  of  non-productive  idle  time. 
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The  econonles  of  scale  arguments,  especially  Grosch's  Law,  have 
been  Increasingly  opposed  In  recent  years.  The  decreasing  cost  of  hardware 
and  the  emergence  of  sophisticated  minicomputers  have  produced  many 
opponents  of  economies  of  scale.  Arguments  against  economies  of  scale 
often  mention  the  high  overhead  found  In  most  large  systems  due  to 
multiprogramming  and  security  support.  In  discussing  diseconomies  of  scale 
Selwyn  states. 

It  was  learned,  for  example  that  the  sharing  overhead  components 
In  one  major  time  sharing  system  then  under  development  would  be 
about  6SZ  of  total  hardware  costs  [14]. 

The  overhead  costs  associated  with  large  central  systems  seemed 
to  be  a major  reason  that  the  city  of  Boise,  Idaho  (case  AA)  acquired  their 
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o%m  minicomputer  to  service  municipal  needs  rather  than  sharing  a larger 
system  with  another  city  or  the  county.  A report  published  by  the  city 
stated. 

The  third  limitation  of  large  centralized  systems  Is  the  cost 
associated  with  large  sophisticated  computers.  For  Boise  City 
this  was  a major  limitation.  While,  Initially,  the  large 
computers  %rere  subject  to  the  benefits  of  economies  of  scale  It 
seems  that  the  largeness  and  complexity  of  such  systems  have 
spawned  even  greater  diseconomies  of  scale.  The  overhead 
encountered  In  multiprogramming,  virtual  memory, 
telecommunications  and  data  bases  Is  far  greater  than  anyone, 
except  possibly  the  hardware  vendors  expected  It  to  be. 

Arguments  against  economies  of  scale  also  Include  (1) 

decentralized  systems  composed  of  uncomplex,  dedicated  computers  can  be 

supported  by  fewer  experts  thereby  decreasing  operating  costs  [17];  and  (2) 

development  time  of  a smaller  (therefore  less  complex)  function  will  be 

shorter  and  therefore  more  economic. 

From  the  controversy  that  exists  today  over  economies  of  scale  we 

might  conclude  that  hardware  costs  have  dropped  to  the  point  that  there  Is 
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no  significant  economic  advantage  to  either  a centralised  or  decentralized 
environment.  The  case  studies  examined  seemed  to  Indicate  that  the 
decision  as  to  tihlch  configuration  Is  more  economic  Is  dependent  upon  the 
particular  application,  the  environment  and  the  prior  experiences  of  those 
making  the  decision  regarding  economies  of  scale.  Economic  considerations 
In  decentralization  decisions  today  seem  to  Involve  more  subtle  Issues  than 
absolute  economies  or  diseconomies  of  scale.  The  considerations  Include 
such  things  as  comsunlcatlons  costs,  entry  costs  and  the  Initial  Investment 
required.  The  following  chart  lists  economic  forces  that  were  significant 
In  user  decisions  regarding  decentralization. 


TABLE  II. 

Economic  Forces  Found 

Low  Entry  Cost 
Low  Initial  Investment 
Fixed  Cost  of  Own  System 
Lower  Communication  Costs 
Smaller  Investment  Than  Upgrading 

3.3.1  Low  Entry  Costs 

A decade  ago  the  capital  required  to  Install  a computer  system 
ranged  from  $150,000  up  to  the  millions.  Today  the  low  end  of  the  range  is 
below  $15,000  and  Is  still  dropping  [18].  Many  decentralization  decisions 
made  today  would  not  be  made  If  the  systems  acquired  required  capital  In 
excess  of  $100,000.  Although  low  entry  costs  are  not  explicitly  stated  as 
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a force  Cowards  deceatrallzatlon  they  are  a precoadltlon  Co  many  of  Chese 
decisions.  Smaller  caplCal  InvesCmenC  requlremenCs  also  make  Che 
acqulslclon  of  compuCer  sysCems  more  possible  aC  lower  organize Clonal 
levels  Chan  was  possible  before.  This  Is  because  in  many  organlzadons 
caplCal  acqulslclon  decisions  are  less  cenCrallzed  for  smaller  caplcal 
amounCs.  The  conclusion  Is  chaC  lower  enCry  coses  remove  Che  economic 
consCralnCs  ChaC  once  prevenCed  decenCralizaclon  decisions  and  also  enable 
Chese  decisions  Co  be  made  aC  lower  managerial  levels. 
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3.3.2  Low  InlClal  InvesCmenC 

Many  cenCrallzed  daca  processing  sysCems  are  based  on  mainframes 
ChaC  cose  anywhere  from  $500,000  co  $12,000,000  [19].  Many  organlzadons 
may  find  IC  dlfflculC  Co  obCaln  Che  caplCal  required  Co  acquire  chese 
mainframes.  In  addlcion  corporaCe  managemenc  may  be  heslCanC  Co  Invesc 
Chis  amoimc  of  money  In  a sysCem  ChaC  (1)  will  noc  be  developed  and 
funcClonlng  for  some  Clme  and  (2)  does  noC  allow  a sCep  by  sCep  analysis  Co 
deCermlne  If  Che  sysCem  will  be  effecClve.  A decenCrallzed  or  discrlbuCed 
sysCem  may  be  much  easier  Co  sell  Co  managemenc. 

In  1969  a group  of  expercs  from  a large  sysCems  house 
pardclpaced  In  a sCudy  of  process  conCrol  requlremenCs  for  a large 
chemical  plane  (case  BB).  The  sCudy  showed  ChaC  Che  resulclng  improvemenCs 
could  supporC  an  expendlcure  of  aC  lease  cwo  million  dollars.  A large 
redundanC  process  conCrol  sysCem  was  presenCed  Co  managemenc.  The  cosC  of 
Che  sysCem  would  be  $1.8  million.  Managemenc  accepCed  Che  resulcs  of  Che 
SCudy  buc  would  noc  Invesc  Che  money  In  chls  large  cencral  sysCem. 
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In  1972  the  same  management  group  accepted  a proposal  for  a 
distributed  process  control  system.  The  distributed  syst«n  could  be 
installed  in  a step-by-step  manner  over  a period  of  t%ro  years.  The  initial 
capital  investment  required  to  determine  the  overall  system's  economic 
feasibility  was  less  than  $100,000  (cost  of  first  step)  compared  with  the 
$1.8  million  required  in  the  1969  proposal.  The  management  decision  was 
much  easier,  because  the  system  would  be  partially  functioning  and  paying 
for  itself  in  six  months  and  because  the  initial  investment  was  low. 

3.3.3  Fixed  Costs 

The  fixed  cost  of  acquiring  a minicomputer  system  seemed  to  be 
preferable  to  paying  out  variable  service  charges  in  two  case  studies  that 
were  examined. 

The  first  case  (case  B)  Involved  the  actuarial  department  of  an 
insurance  firm.  The  department  used  a time-sharing  service  but  wanted  to 
do  more  research  involving  actuarial  simulations.  A user  in  the  department 
said 

The  idea  of  having  our  own  minicomputer  with  fixed  cost,  no 
matter  how  much  time  we  used  it,  had  a lot  of  appeal.  Mow  we 
don't  mind  letting  the  mini  run  for  four  or  five  hours. 

A theoretical  chemist  at  Berkeley  (case  CC)  experimented  with  the 
feasibility  of  using  a dedicated  minicomputer  for  very  large  scale 
theoretical  chemistry  computations.  The  chemist  and  his  graduate  students 
had  been  using  the  CYBER  7600  central  processor  at  the  Lawrence  Berkeley 
Laboratory  but  felt  that  their  annual  budget  for  computer  time  was  buying 
them  a negligible  amount  of  cpu  time  on  this  large  machine.  The  chemist 
acquired  a minicomputer  and  began  to  run  many  of  the  applications  on  this 
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machine.  His  conclusion  was  that  it  was  feasible  to  invest  the  annual 
budgets  for  computer  time  of  two  university  scientists  In  a minicomputer. 

He  attempts  to  show  that  the  minicomputer  provides  him  with  three  times 
more  computing  power  per  dollar  than  the  CYBER  7600.  This  calculation  Is 
debatable,  however  It  appears  that  the  Idea  of  obtaining  a dedicated 
computer  for  a fixed  and  affordable  price  was  preferable  to  him  than  paying 
for  cpu  time  on  a central  machine. 

3.3.4  Lower  Communication  Costs 

In  many  situations  remote  terminal  capability  will  satisfy  the 
needs  of  a user  department  functionally  and  psychologically.  However 
remote  access  requires  communication  capability  and  this  entails  an 
additional  expense  that  seems  to  be  becoming  more  significant.  One  author 
states  that  of  all  the  elements  of  computing  cost  the  smallest  decrease  In 
recent  years  is  represented  by  the  communications  portlon[da4] . 
Communication  costs  seem  to  make  up  more  and  more  of  the  costs  of  r^ote 
computing.  This  has  been  mentioned  as  a major  force  towards 
decentralization,  which  requires  significantly  less  communication 
facilities. 

The  Jewelry  firm  of  Llsner/Rlchelleu  of  Rhode  Island  (case  DD) 
sought  to  reduce  costs  Incurred  bv  financial  data  processing.  They  had 
formerly  used  data  entry  terminals  connected  by  telephone  lines  to  the 
firm's  central  computer  facility.  These  terminals  were  on-line  eight  hours 
a day  and  telephone  costs  were  high.  This  was  a force  In  their  decision  to 
seek  an  alternative  method  of  processing  \fhlch  eventually  resulted  In  the 
purchase  of  a dedicated  mini. 
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A large  corrugated  container  manufacturer  (case  EE)  wanted  to 
totally  automate  a formerly  manual  Inventory  control  system.  In  deciding 
tfhether  to  Install  remote  terminals  at  the  Individual  plants  the  company 
was  faced  with  the  question  of  communication  costs.  Their  conclusion  was 
that  a central  system  connected  to  remote  locations  by  communication  lines 
would  Incur  large  communication  costs  and  this  was  a major  reason  for  their 
eventual  decision  to  organize  the  Inventory  control  system  In  a distributed 
way. 

3.3.5  Smaller  Investment  Than  Upgrading  Central  System 

In  many  cases  upgrading  a mainframe  for  a new  application  Is 
difficult  to  do  and  may  cause  Interference  problems.  In  addition  this 
upgrading  may  be  more  expensive  than  Implementing  the  new  application  on  a 
dedicated  minicomputer. 

In  a case  study  Involving  the  corporate  division  of  a service 
company  (case  H)  the  decision  was  whether  to  Implement  a new  on-line  data 
entry  system  on  a mini  or  on  a portion  of  a large  batch  machine.  Their 
analysis  Indicated  that  the  upgrading  of  the  batch  would  be  more  expensive 
than  development  of  a dedicated  system.  The  smaller  Investment  required  to 
Implement  the  system  on  a dedicated  minicomputer  was  a major  force  In  the 
decision  to  decentralize  this  function. 

3.4  Psychological  Forces 

A psychological  force  Is  one  whose  source  Is  an  emotion,  a 
philosophy,  a preference  or  a perception.  We  conjecture  that  as  hardware 
costs  continue  to  drop  and  as  technological  advances  allow  sophisticated 
networking  of  computers,  psychological  forces  may  be  the  deciding  factor  In 
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3.4.1  Bed  Experiences  With  the  Central  System 

Case  studies  seemed  to  Indicate  that  many  decentralisation 

decisions  are  made  specifically  because  of  former  experience  with  a central 

system.  Like  many  kinds  of  business  declslon-maklng,  decisions  are 

sometimes  made  In  reaction  to  previous  experiences. 

Some  users  acquire  local  dedicated  computer  resources  because 

they  have  found  the  central  system  unresponsive.  Inflexible,  slow-reacting 

or  expensive.  This  experience  with  the  central  system  forces  them  to 

consider  other  alternatives.  George  Glaser  says 

If  a user  has  a problem  and  Is  determined  to  solve  It,  and  If  he 
cannot  get  an  acceptable  solution  to  his  problem  from  the  'legal' 
source  of  help,  he  will  seek  (and  find)  illegal  sources  [6]. 

Industrial  Nucleonics  Corporation  (case  P)  formerly  used  a 

central  batch  computer  for  planning  production  and  handling  Inventory.  The 

problems  they  experienced  with  this  system  were: 

1.  lag  time  between  Inventory  change  and  report 
receipt 

2.  priority  conflicts  at  the  data  processing  center 

3.  data  preparation  Inaccuracies  because  keypuncher 
was  not  familiar  with  manufacturing  terms 

These  problems  forced  them  to  consider  other  alternatives  and  eventually 

led  to  the  acquisition  of  a dedicated  system  for  production  and  Inventory 

control. 

First  National  Citibank  of  New  York  (case  FF)  was  one  of  the  most 

public  In  their  decision  to  decentralize  computer  operations.  In  the 

1960's  Citibank  automated  many  of  their  applications  with  large  computers 

controlled  by  a central  department.  The  following  Is  a Citibank 

description  of  their  experiences  with  a central  computer  system. 

To  support  this  automation,  we  built  large  data  centers  with 
sophisticated  hardware.  We  talked  at  the  time  of  the  economies 
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of  hardware  centralization  and  economies  of  scale.  We  staffed 
our  data  processing  organization  with  sophisticated  technical 
resources  to  program  and  run  these  computers.  Data  processing 
became  an  Institution  with  Its  own  culture,  jargon  and  management 
process.  Over  time  the  data  processing  people  developed  a new 
language  separate  from  the  line  manager.  Communication  barriers 
resulted — the  line  didn't  speak  computerese  and  the  data 
processer  didn't  speak  business. 

According  to  Citibank's  Vice  President  of  Data  Processing,  things  had 
gotten  so  bad  with  the  large  central  department  that  a simple  request  for 
Information  had  to  go  through  a dozen  people  and  took  ten  days  to  complete. 
"If  1 didn't  have  ten  days  I would  write  It  off  to  a tape  and  take  it  to  a 
service  bureau."  [source  2]  It  appears  that  bad  experiences  with  the 
centred  system  were  the  major  force  In  Citibank's  decentralization 
decision. 


A large  commercial  bank  (cene  K)  attempted  to  automate  money  desk 
operations  using  a centralized  system.  Because  of  the  complexity  of 
program  development,  functions  were  often  obsolete  by  the  time  they  were 
developed.  After  years  of  attempting  to  develop  a central  system  the  bank 
began  to  search  for  other  alternatives.  This  led  eventually  to  the 
Imple  mentation  of  a decentralized  system. 

Many  case  studies,  mentioned  In  previous  sections.  Involved 
organizations  that  were  former  users  of  central  systems.  Their 
decentralization  decisions  often  resulted  from  a dissatisfaction  with  their 
central  systems.  The  point  Is  that  In  some  cases  It  Is  possible  that  with 
certain  modifications  or  changes  In  policy  and  personnel,  the  central 
systems  would  have  been  satisfactory.  However,  In  many  cases  the  former 
experiences  preclude  any  consideration  of  this  alternative.  For  this 
reason,  bad  experiences  with  a central  system  are  considered  a 
psychological  force. 
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3.4.2  User  Acceptence 

An  edventage  often  noted  of  decentralised  computer  systesu  Is 
that  they  insure  a greater  degree  of  user  acceptance.  The  reasons  for  this 
may  include  (1)  the  system  can  be  closely  tailored  to  the  user's  needs  (2) 
the  user  has  responsibility  and  will  not  be  able  to  blame  anyone  else  if 
anything  goes  wrong  and  (3)  the  user  is  assured  that  data  processing 
performance  is  measured  by  how  well  his  business  performs. 

In  the  following  two  case  studies,  corporate  management's  desire 
to  achieve  a greater  degree  of  user  acceptance  was  mentioned  as  a prominent 
force  in  their  decision  to  decentralize. 

A major  railroad  (case  GG)  wished  to  develop  a system  to  keep 
track  of  freight  car  location  both  between  and  within  freight  yards  in 
order  to  improve  utilization.  They  Initially  used  a central  system  with 
remote  terminals  located  in  each  yard.  Local  yardmasters  did  not  fully 
utilize  this  system  however  and  the  system  was  considered  unsuccessful.  In 
an  effort  to  implement  a system  that  local  personnel  would  accept,  central 
management  replaced  the  central  system  with  a decentralized  one.  They 
installed  dedicated  minicomputers  in  each  freight  yard  and  this  allowed  the 
system  to  be  tailored  to  the  needs  of  the  personnel  in  each  yard  who  would 
actually  use  the  system.  The  railroad  company  seemed  to  feel  that  this 
system  would  insure  a greater  degree  of  user  acceptance. 

Boise  City,  Idaho  (case  AA)  first  experimented  with  the  idea  of  a 
decentralized  computer  system  when  they  installed  a minicomputer  in  the 
Boise  Public  Library.  The  results  of  this  installation  seemed  to  have  an 
Impact  upon  their  eventual  decision  to  acquire  their  own  municipal  computer 
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system  rather  than  sharing  a large  central  system  with  other  cities,  which 

Is  typically  the  case  with  small  city  governments. 

....It  can  be  anticipated  that  the  Installation  of  minicomputers 
will  Improve  user  acceptance  of  such  systems.  The  circulation 
system  Installed  In  the  Boise  Public  Library  Is  thought  of  as  the 
Library's  computer.  When  the  system  goes  down  It  Is  still  the 
Library's  system,  not  a system  belonging  to  the  data  processing 
department.  This  attitude  Is  a result  of  the  fact  that  the 
hardware  Is  close  to  and  under  the  control  of  the  people  «rtto  use 
It.  This  has  been  an  Important  factor  In  the  success  and  overall 
user  acceptance  of  the  library  system. 


3.4.3  Fewer  Political  and  Priority  Conflicts 

In  an  article  entitled  "Power,  Politics  and  DP,"  Joseph  Rue 

points  out 

It  does  not  take  lo*'^  for  a dp  manager  to  realize  that  users  are 
not  really  "departments",  "functions",  or  "projects"  but  rather 
certain  people  who  are  pursuing  personal  purposes  within  the 
organization's  power  structure  [20]. 

Data  processing  Involves  Information,  which  Is  of  major  Importance  to  an 
organization.  There  seems  to  be  a certain  amount  of  power  related  to 
control  of  Information  In  organizations.  This,  according  to  Rue,  Is  why  a 
dp  department  ^perlences  conflicts  and  difficulties  In  Its  relationship  to 
other  departments  In  an  organization.  Other  departments  or  people  require 
the  Information  that  dp  provides  and  these  people  are  competing  with  each 
ocher  for  priority.  Avoidance  of  the  politics  of  the  centralized  data 
processing  function  was  mentlc-aed  In  the  following  case  study  of  a 
decentralization  decision. 

The  Data  Tech  Division  of  Penrll  Corporation  (case  HH)  has  a 
minicomputer  for  manufacturing  operations  but  uses  a service  bureau  for 
financial  applications.  According  to  Che  controller  Che  functions  are 
split  primarily  because  "the  service  bureau  can  do  a better  job."  However, 
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he  also  aentioned  "there  are  no  conflicts  between  the  needs  of  accounting 
and  aanufacturlng.  This  aeans.  In  essence,  that  there's  not  tine  wasted 
with  politicking  or  enplre  building.  Priorities  are  always  clearly  drawn: 
get  the  Job  done  for  the  conpany  as  a %rtiole." 

3.4.4  Philosophy  of  the  Organisation 

Several  authors  have  noted  that  centralized  data  processing  In  a 
decentralized  nanagenent  environment  Is  contradictory  and  dat:gerous[5,6]. 

A decentralized  management  philosophy  gives  profit  and  loss  responsibility 
to  organizational  units  and  provides  unit  managers  with  all  the  resources 
required  to  accomplish  the  task.  To  overlay  a central  data  proccesslng 
facility  on  an  organization  of  this  sort  may  result  In  conflicts  and 
confusion.  In  several  of  the  case  studies  examined  the  organization  opted 
for  a decentralized  computer  facility  because  It  was  more  In  line  with 
management's  philosophy  than  a central  facility. 

An  engineering  firm  (case  C)  formerly  used  service  bureaus  to 
serve  the  needs  of  Its  offices  across  the  United  States,  The  firm  has  very 
decentralized  management  and  gives  much  responsibility  to  division 
managers.  The  company  decided  to  acquire  an  In-house  system  and  they 
considered  both  a central  computer  Implementation  and  one  with 
minicomputers  Installed  In  the  various  offices.  Their  decision  was  to 
Implement  the  decentralized  system  because  It  gave  them  the  opportunity  to 
maintain  their  decentralized  operating  philosophy. 

A European  division  of  a large  multinational  manufacturer  (case 
II)  decided  to  Implement  a distributed  data  collection  system.  This 
system,  which  spans  the  continent.  Includes  eleven  mini coaq>uters  and  a 
central  machine.  One  of  the  major  reasons  they  Implemented  a distributed 
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system  is  because  they  felt  that  distributed  data  processing  would  fit  well 
with  the  autonomous  nature  of  their  different  divisions. 

W.  R.  Grace  Corporation  (case  JJ)  Is  a very  decentralized  company 
PI  managerlally.  In  line  with  this  the  company  gives  major  control  of 

computer  systems  to  their  various  divisions.  The  central  department 

approves  computer  purchases,  attempts  some  standardization  to  allow  I 

'i 

transfer  of  staff  and  programs  and  Is  responsible  for  conducting  a yearly  i 

i 

survey  of  all  data  processing  operations.  However,  each  division  maintains 
responlblllty  for  all  other  aspects  of  Its  own  computer  system. 

First  National  Citibank  of  New  York  (case  FF)  decentralized  their 
computer  operations  In  line  with  a corporate  philosophy  that  managers 
should  have  complete  control  over  all  aspects  of  the  process  for  which  they 
are  responsible.  In  1970  Citibank  reorganized  Its  management  structure  in 
hopes  of  reducing  operating  costs  brought  on  from  the  tremendous  growth  of 
the  financial  services  sector.  The  bank  broke  up  large  functional 
organizations  Into  product  groups  and  gave  line  managers  full 
responsibility  for  Individual  products.  A manager's  performance  was 
measured  by  his  unit's  cost  performance.  However,  In  the  midst  of  this 
move  to  decentralized  management  Citibank  had  maintained  a central  computer 
system.  By  1974  the  bank  realized  that  a central  processing  system  meant 
managers  did  not  have  control  of  the  necessary  resources  to  meet  their 
responsibilities.  In  1974  the  company  began  a decentralization  of  Its  data 
processing  function  which  continues  today. 
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3.5  Significant  Centralisation  Forces 
3, 5. 1 Economies  of  Scale 

The  argument  for  economies  of  scale  in  computer  use  was  a 
significant  centralisation  force  in  the  1960's  and  in  many  cases  it 
continues  to  be  today.  It  is  unimportant  whether  these  economies  do  in 
fact  exist.  What  is  important  is  that  many  organisations  continue  to 
believe  in  and  support  the  existence  of  economies  of  scale.  This  force  is 
most  apparent  in  arguments  that  first  arose  In  1972  between  state  and  city 
governments  and  the  Federal  Bureau  of  Investigation. 

An  FBI  regulation  (case  R)  issued  in  1972  required  that  any 
computer  handling  criminal  histories  "be  dedicated  to  law  enforcement 
purposes  and  be  under  the  management  control  of  a law  enforcement  agency." 
This  would  require  that  states  maintain  dedicated  computer  systems  for  law 
enforcement.  State  and  city  governments  objected  strongly  to  this 
regulation  on  the  grounds  that  it  would  greatly  increase  their  data 
processing  costs  to  operate  anything  but  a central  system  and  that  this 
would  have  serious  fiscal  impact. 

An  article  in  Computerworld  in  1975  noted  the  trend  in  various 
states  towards  centralization  of  their  data  processing  systems.  Kentucky 
reported  saving  $2.4  million/year  since  consolidating  their  data  processing 
onto  one  large  machine.  This  consolidation  was  aimed  at  lowering  costs  and 
was  achieved  in  spite  of  severe  opposition  from  user  agencies  which 
maintained  their  own  machines.  Mississippi's  Central  Data  processing 
Authority  reported  to  have  saved  $500,000  annually  since  centralizing  l21]. 
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In  1975  the  state  of  Arizona  (case  KK)  consolidated  from  sixteen 


to  six  cpu's  "to  do  something  about  excessive  spending 


Acme  Markets,  Inc.  (case  LL),  wished  to  reduce  data  processing 
costs  which  led  them  to  centralize  operetlons.  Previously  equipment  was 


decentralized  but  the  company  felt  that  this  approach  led  to  no 


standardization  of  applications  software  and  little  control  over  data 


processing  costs.  According  to  the  manager  of  DP  operations  they  Installed 


a remote  batch  network  because 


We  wanted  to  reduce  the  total  costs  at  the  remote  locations  and 
eliminate  duplicating  people  at  each  location. 


Selwyn  conducted  a study  of  10,000  cooq>uters  Installed  at  firms 


In  manufacturing  Industries  (case  Ml)  to  determine  whether  or  not  the 


He  concludes 


*^)sers  did  operate  computers  as  If  there  «rere  significant  economies  of 


scale  In  their  use 


capacities  required  by  an  arbitrary  firm  given  the  size  of  the  firm.  He 


then  coetpared  this  estimate  to  the  actual  acquisition  patterns  of  the  firms 


In  the  study  and  detemlned  that  many  users  acquired  computers  much  larger 


than  those  necessary  to  meet  their  data  processing  needs 


3. 5. 2 Management  (k>ntrol/Integratlon 


Centralization's  strongest  point  seems  to  be  the  potential  that 


It  offers  for  sharing  and  the  tight  management  controls  It  can  supply 


through  standardization  of  data  files,  programming  and  documentation,  and 


reporting.  The  following  case  studies  showed  this  to  be  a significant 


force  towardi*  centralization  of  an  organization's  computer  system 
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Until  1975  law  enforcement  officials  in  Boston  (case  NM)  were 
unable  to  do  much  about  parking  violations.  Each  of  the  nine  district 
courts  in  the  city  handled  these  violations  differently,  which  meant  that 
some  used  manual  systems  to  record  violations  while  others  used  computer 
support.  This  made  it  impossible  to  relate  violations  in  one  district  to 
those  in  another  district.  In  order  to  accomodate  sharing  of  information 
across  the  various  district  courts  so  that  officials  could  begin  to  "crack 
down"  on  perpetual  offenders,  Boston  implemented  a central  computer  system. 
This  system  linked  the  separate  courts  to  the  police  department  and  the 
Registry  of  Motor  Vehicle's  through  a central  computer  in  Boston  City  Hall. 

Jones  and  Laughlin  Steel  Corporation  (case  00)  of  Pittsburgh 
centralised  their  computers  in  particular  to  "bring  centralised  data  base 
capability  to  the  firm." 

Burroughs  Corporation  (case  PP)  centralised  the  development  and 
design  of  its  internal  systems  in  order  to  enforce  standard  reporting. 
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4.1  Sunmary  of  Conjecture  and  Results 

We  have  examined  over  forty  case  studies  of  computer 
decentralization  decisions  and  have  tried  to  determine  and  catalogue  the 
forces  b^lnd  these  decisions.  A complete  listing  of  the  forces  determined 
to  be  significant  In  these  decisions  Is  found  In  TABLE  IV. 


TABLE  IV. 


DECEMTRALIZATION  FORCES  FOUND 


Functional 


Flexibility 

Availability  and  Accessibility 

Ability  to  Set  Priorities 

Ability  to  Regulate  Response  Time 

Ability  to  Regulate  Hardware  and  Software  Upgrades 

Avoidance  of  Overhead  on  Mainframe 

Shorter  Development  Time  Because  Less  Complexity 

Privacy  and  Security  Issues 

Reliability 

Economic 

Low  Entry  Costs 

Low  Initial  Investment 

Fixed  Cost  of  Own  System 

Lower  Communication  Costs 

Smaller  Investment  Than  Upgrading 

PsTcholomlcal 

Bad  Experiences  With  a Central  System 
Insures  Greater  User  Acceptance 
Fewer  Political  and  Priority  Conflicts 
Philosophy  of  Organisation 


The  conjecture  Is  that  there  are  significant  forces  In  many 
organisations  towards  decentralisation  of  the  computer  facility,  that  have 
been  held  In  check  until  recently  by  economic  and  technological 
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constraints.  The  economic  constraint  is  clearly  vanishing  as  hardware 
costs  drop.  The  technological  constraint  is  present  but  it  may  be 
overlooked  in  acquisition  decisions*  especially  if  these  decisions  are 
initiated  at  lower  levels  in  the  organisation.  The  relaxation  of  these 
constraints  seems  to  be  releasing  forces  resulting  in  decentralization 
decisions  at  all  levels  in  the  organisation.  The  significance  of  these 
forces  may  be  Judged  by  their  ability  to  withstand  trends  in  the  computer 
industry.  For  example,  we  do  not  consider  economies  of  scale  a significant 
force  towards  centralization  because  the  drop  in  hardware  costs  will 
continue  and  economies  of  scale  are  dependent  on  this  trend  in  the  computer 
Industry.  However,  psychological  forces  leading  towards  decentralization 
decisions  seem  to  be  Inherently  independent  of  the  coi^uter  industry  and 
are  therefore  considered  significant. 

The  results  Indicate  that: 

1.  Hardware  costs  have  dropped  to  the  point  that  economies  of 
scale  arguments  no  longer  Influence  decisions  to  the  extent  that 
they  have  in  the  past.  Many  organizations  are  obtaining 
dedicated  computer  systems  and  are  even  claiming  substantial 
savings  through  their  actions. 

2.  The  major  forces  encouraging  centralization  of  a computer 
system  affect  corporate  management  primarily  and  are  industry 
dependent.  These  forces  are  (1)  lingering  faith  in  economies  of 
scale  and  (2)  the  ability  for  sharing  and  management  control  in  a 
central  system.  We  conjecture  that  economies  of  scale  arguments 
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are  less  significant  as  time  passes.  In  addition  as  the 
technological  problems  of  networking  loosely  coupled  computers 
and  distributing  data  bases  are  solved,  the  last  force  will 
become  less  significant. 

3.  The  forces  towards  decentralization  Include  many  that  Involve 
function,  l.e.  better  service  of  users'  needs  by  the  system.  In 
addition  there  are  psychological  forces  behind  decentralization 
Including  Increased  user  acceptance  and  ability  to  fit  the  system 
to  the  organization  with  minimal  problems.  The  recent  concern 
that  "user-oriented"  systems  are  developed  seems  to  be  a 
recognition  of  these  psychological  forces. 

4.  Decentralization  decisions  are  made  at  low  levels  In  the 
organization  as  well  as  at  corporate  levels.  The  drop  In 
hardware  costs  enables  operational  managers  to  acquire  and 
support  a dedicated  computer  system. 

5.  Many  decentralization  decisions  Involve  applications  that 
would  require  upgrade  of  a mainframe  If  they  were  liq>lemented  on 
the  central  system. 

4. 2 Consequences 

The  results  Indicate  that  decentralization  forces  do  exist  In 
many  organizations.  The  drop  In  hardware  costs  and  the  Increasing 
sophistication  of  the  minicomputer  allows  a manager  to  obtain  a powerful. 
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local  computer  for  a relatively  small  Investment.  For  these  reasons, 
decentralisation  forces  have  become  more  visible. 

The  consequences  of  the  existence  of  strong  decentralization 
forces  could  Include  the  disintegration  of  the  organization's  Information 
system.  Low  entry  costs  allow  decentralization  decisions  to  be  made  by 
lower-level  managers.  While  Isolated  Instances  of  this  decision  would  not 
be  significant,  a large  number  of  these  localized  decisions  could  create 
chaos.  First,  Incompatabllltles  among  the  computer  systems  of  local  units 
may  prevent  these  these  units  from  sharing  data  or  programs.  The  current 
state  of  technology  Is  the  source  of  this  problem.  Networking  of  loosely 
coupled  computers  Is  not  yet  well  understood.  One  hopes  that  technological 
advances  within  the  next  few  years  will  alleviate  the  Integration  and 
sharing  problems  in  decentralization.  Second,  a local  system  allows  a 
department  manager  to  "Interpret"  the  data  in  his  system  In  a number  of 
ways.  The  computer  system  that  the  unit  uses  will  provide  some  of  this 
"Intepretatlon"  In  the  way  It  stores  and  manipulates  data.  Designers  of 
application  programs  provide  further  "Interpretation"  of  data  through  the 
algorithms  they  use  In  their  programs.  A lack  of  consistency  throughout 
the  organization  In  Interpreting  data  may  provide  management  control 
problems. 

We  do  not  feel  that  decentralization  should  be  "outlawed"  or  even 
discouraged,  because  there  are  advantages  to  be  enjoyed  from 
decentralization.  However  corporate  management  should  be  aware  of  the 
current  technological  constraints.  Compatablllty  between  machines  can  be 
assured  If  proper  thought  Is  given  to  equipment  procurement. 
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4.3  Future  Work 

This  thesis  Is  an  attempt  to  extend  previous  work  done  In  the 
area  of  decentralization  of  an  organizational  computer  system.  The 
distinguishing  feature  of  this  thesis  from  previous  work  Is  that  It 
explores  decentralization  decisions  through  numerous  case  studies.  In  an 


effort  to  show  that  there  are  forces  towards  decentralization  that  may  In 
the  future,  cause  these  decisions  to  be  made  at  lower  and  lower  levels  In 
the  organization. 

Section  4.2,  which  related  the  methods  used  In  this  research 
noted  the  limitations  Inherent  In  examining  case  studies  obtained  from 
computer  community  .Mterature.  The  first  limitation  Is  that  the  forces 
that  are  revealed  may  or  may  not  be  the  ones  that  actually  were  the  cause 
of  the  decentralization  decision.  These  cases  are  presented  In  the 
literature  In  a way  that  Is  highly  dependent  upon  the  perception  of  the 
manager  relating  the  case  and  trhat  that  manager  wishes  to  reveal  about  the 
decision.  The  second  limitation  Is  that  certain  categories  of  decisions 
are  excluded  from  the  literature.  These  cases  may  Involve  decisions  made 
by  lower  level  managers  who  wish  to  avoid  publicity  for  political  reasons, 
or  %rho  have  no  reason  to  publicly  cite  why,  where  and  how  they  acquired  a 
dedicated  computer  system.  These  cases  are  the  most  Interesting  and 
unfortunately  the  rarest  In  the  literature. 

We  feel  that  future  work  Is  required  In  this  area  to  extend  and 
Improve  the  work  done  here.  This  future  %rork  should  employ  an  Interview 
method  to  obtain  case  studies.  Confidential  conversations  with  managers  of 
organizations  unwilling  to  discuss  their  decentralization  decisions 
publicly  could  yield  more  significant  and  viable  results.  In  addition. 
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this  approach  would  allow  more  access  to  management  decisions  made  at  lower 
levels  in  the  organization.  Comprehensive  exploration  of  acquisition 
patterns  and  the  reasons  for  the  acquisitions  in  only  one  organization 
would  add  to  the  understanding  of  decentralization  decisions  in 
organizations.  Similarly,  a better  assessment  of  the  future  impact  of 
these  decisions  on  computer  systems  could  be  determined. 
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Code  Description  of  Case  Study/Source 

A Datascope  Corporation,  Source:  “Firm's  Figures 

Show  Mini  Use  Justified,"  Computerworld. 
January  10,  1977 


B actuarial  department  of  an  unidentified  insurance 

firm.  Source:  "Actuaries  Say  T/S  Can't  Compare 
to  Dedicated  Mini,"  Computerworld.  February  2,  1976 


i 


C unidentified  engineering  firm.  Source:  Burnett, 

Gerald,  J. , and  Richard  Nolan,  "At  Last  Major 
Roles  for  Minicomputers,"  Harvard  Business  Review. 
May-June  1975 

D Lowe's  Companies,  Inc.,  Source:  Acree,  John, 

"Putting  the  Principle  Into  Practice,"  Data  Systems. 
February,  1975 


E Ricardo  Consulting  Engineers,  Source:  "Mini  Helps 

Control  Engine  Test  Beds,"  Computerworld. 

May  23,  1977 

F Atlanta's  First  National  Bank,  Source:  "Small  Bank 

Division  Sets  Up  Its  Own  Mini  Computer," 
Computerworld . March  12,  1975 

G Deere  and  Company,  Source:  Vaughan,  Frank, 

"Small  Users'  Needs  Paramount  Corporate  DP 
Managers  Warned,"  Computerworld . June  20,  1977 

H corporate  division  of  unidentified  service  company. 

Source:  Burnett,  Gerald  J. , and  Richard  Nolan, 

"At  Last  Major  Roles  for  Minicomputers,"  Harvard 
Business  Review.  May-June  1975 

I Office  Canteens  of  Manhattan,  Source:  "Small  System 

Helps  Fast  Food  Firm  Respond  to  Change," 
Computerworld.  June  6,  1977 

J Chrysler  Corporation,  Source:  "Distributed  Mini 

Approach  Protects  Response  Time,"  Computerworld. 
April  9,  1975 

R an  unidentified  commercial  bank.  Source: 

Confidential  communication  with  a vendor 
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unidentified  wholesale  manufacturing  firm.  Source: 
Burnett,  Gerald  J.,  and  Richard  Nolan,  "At  Laat 
Major  Roles  for  Minicomputers,"  Harvard  Business  Review. 
May-June  1975 

Retail  Installment  Loan  Department  of  Wachovia 
Bank  and  Trust  Company,  Source:  "Mini  Dedicated 
to  Preprocessing  Increases  Bank's  Loan  Capacity," 
Computerworld.  January  31,  1977 

Ollnkraft,  Inc.  Mill  Division,  Source:  "Mini  Saves 
Time  on  Mainframe,"  Computerworld . July  30,  1975 

unidentified  railroad  company.  Source:  Confidential 
communication  with  a vendor 

Industrial  Nucleonics,  Inc.,  Source:  Ward,  Patrick, 

"User  Finds  Work  Divided  Is  Easily  Conquered," 
Computerworld . January  8,  1975 

unidentified  chemical  plant  division.  Source: 
Confidential  communication  with  a vendor 

FBI  Regulation,  Sources:  1)  French,  Nancy,  "States 
Blast  NCIC  Requirement  for  Dedicated  Systems," 
Computerworld.  July  30,  1975;  2)  Lundell,  E.  Drake,  Jr. 
"Cities  Not  Happy  With  FBI  Data  Bank  Rules," 
Computerworld . January  12,  1972;  3)  Smalhelser,  Marvin 
"California  DOJ  Opposes  Proposal  for  Dedicated  Justice 
Systems,"  Computerworld.  May  29,  1974 

Central  Congress  for  Privacy  and  Protection, 

Source:  "Hiroshima  Bomb  Victims  Fight  Plan  to 
Centralize  Health  Data,"  Computerworld . August  6,  1975 

Arizona  governor.  Source:  Ward,  Patrick,  "Centralization 
of  Data  Systems  Continuing  Despite  Resistance," 
Computerworld.  January  1,  1975 

Georgia  State  Crime  Lab,  Source:  "Crime  Lab 
Decides  Security  the  Motive  As  It  Picks  Mini  to 
Watch  Evidence,"  Computerworld.  May  17,  1976 

Lockwood-McDonald  Hospital,  Source:  "Small  In-House 
System  Saves  $12,000,"  Coisputerworld.  June  25,  1975 

Inter-Provlnclal  Pipeline  Company,  Source:  Speers, 

D.  S.,  "Monitoring /Control  By  Distributed  Computing" 
Datamation.  July  1973 
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3.2.6 
3.4.1 

3.2.7 


3.2.8 

3.5.1 


3.2.8 
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ARPANET  IMP  Systenii  Source:  Schantz,  R.  E. , 
"Protocols  for  Utilizing  Redundant  Processes  In 
a Computer  Network,"  Proceedings  of  the  Srh  Texas 
Conference  on  Computer  Systems.  October  1976 


Southern  Bell  Telephone  and  Telegraph,  Source: 
Canning,  Richard  G. , "Structures  for  Future  Systems 
EDP  Analyzer.  August  1974 


Boise  City,  Idaho,  Source:  DeGroff,  William  J., 
"Minicomputers:  Boise's  Approach  to  an  Integrated 
Municipal  Information  System,"  Boise  Center  for  Urban 
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